1. Field of the Invention
The present invention relates in general to the field of program code conversion for computer systems and in particular, but not exclusively, to the field of emulation using dynamic binary translation.
2. Description of Related Art
A program for a computer takes several different forms. Typically a program is written first in a high-level language readily understood by a human programmer. The program is compiled from the high-level language into a low-level language more appropriate for control of a computer's processor and related components. However, in order for the processor to function, the program code must be provided in a machine-readable form that directs primitive operations of the processor such as loading, shifting, adding and storing operations. To run faster, some processors use an expanded set of instructions each of which represent a sequence of primitive instructions. This is known as a complicated instruction set computer (CISC). However, program code written (or compiled) specifically for a first processor with a particular instruction set in most cases cannot run on any other type of processor because of differences between the instruction set for each type of processor.
An emulator allows program code written for a processor of a first type (a “subject” processor) to be run on a processor of a second type (a “target” or “host” processor). One form of this emulation process is known as binary translation because executable binary code appropriate to the subject processor is translated into executable binary code appropriate to the target processor.
In static binary translation an entire program is translated prior to execution of the translated program on the target processor. This involves a significant delay. Therefore, emulators have been developed which employ dynamic binary translation to translate small sections of a source program for execution immediately on the target processor. This is much more efficient because large sections of the source code will not be used in practice, or will be used only rarely. An emulator employing a dynamic translation system selects only the required parts of the source program for translation on demand, as the program is run.
There now follows a brief summary of dynamic binary translation for an emulator as may be employed in a preferred embodiment of the present invention. More detailed background in the field of dynamic binary translation is given in the applicant's co-pending application number GB 98 22075.9 entitled “PROGRAM CODE CONVERSION” the content of which is incorporated herein by reference to avoid wasteful duplication.
When performing dynamic binary translation the emulator appears to the subject code as if the subject code were running on the appropriate subject processor. The emulator replicates the subject machine including, for example, registers of the subject processor, such that the emulator provides a virtual subject machine. The emulated registers are termed herein “abstract registers” and correspond to the set of registers of the subject processor used by the subject code. In the preferred dynamic translation process the emulator first translates a predetermined small section of the subject code into an intermediate representation which represents the instructions of the subject code in a generic format, optionally performs optimisation on the intermediate representation, and then translates the optimised intermediate representation into executable binary code for the target processor. It is preferred that the small section of subject code corresponds to a “basic block” which starts with a first instruction at a unique entry point and ends at a last instruction at an unique exit point. Typically the last instruction of the block is a jump, call or branch instruction (conditional or unconditional).
In the field of binary translation, a problem arises with respect to the handling of exceptions. An exception indicates that a condition has occurred which needs to be handled before processing can continue. This includes explicit exceptions performed as an instruction in the subject code (for example an exception is reported if the value of one register is greater than the value of a second register), and implicit exceptions which occur for example as a result of memory read or write operations to a memory page that is not currently available. In both cases the exception is desirably reported to an exception handler written in subject code. However, many subject machine architecture definitions require that the exception is reported on a boundary between subject code instructions, following a predetermined set of rules. For example, the subject architecture definition may require that when the exception is reported, the effects of all previous subject instructions are complete, the exception points to the first instruction of the subject code which has not been executed and no effects from that subject instruction or any subsequent instruction have yet taken place. Further, the architecture definition of a particular processor may have different rules for different types of exceptions.
In the context of binary translation it is apparent that a target instruction performed on the target processor that causes an exception to be reported will not of itself fulfil the conditions for reporting the exception to an exception handler written in subject code. Instructions are almost always performed on the target processor in a different order compared with the order of instructions in the corresponding block of subject code, firstly due to the differences between the instruction set of the subject processor for which the subject code was written and the target processor on which the translated target code is run, and secondly because of the optimisation of the intermediate representation that typically occurs during translation.
Exceptions can occur in response to execution of the translated target code on the target processor, and can occur during execution of the emulator code on the target processor, i.e. during translation. In order to report an exception to the subject exception handler the state of the virtual subject processor represented by the emulator must be available to the subject exception handler, including the correct status of the registers of the subject processor.
One approach to this problem is to return the virtual subject machine to the conditions that applied at entry into the section of code being translated or executed, i.e. by returning the virtual subject machine to the condition prevailing at the point of entry into the current block of subject code instructions being translated or executed. The exception handler can now step through the instructions of the block of source code individually in sequence until the instruction causing the exception is identified.
U.S. Pat. No. 5,832,205 (Kelly et al) discloses an emulator which uses a set of “working” registers during emulation of each section of subject code. The content of each of these working registers is copied to a set of “official” virtual subject registers at the end of the section of subject code, using a gated store buffer. Therefore, if an exception occurs during emulation of a section of subject code this will affect only the working registers and the condition of the virtual subject machine can be recovered from the “official” registers at the point of entry into that section of subject code. However, the use of “working” and “official” registers adds significantly to the overhead of the emulation process in the target processor due to the copying of information from the “working” registers to the corresponding “official” registers at the end of each section of subject code.